A list of references is set forth at the close of the present disclosure; individual references from the list are referred to herebelow numerically (i.e., [1], [2], [3], etc . . . ).
As networks continue to grow in size and complexity, system administrators are faced with an ever-increasing volume of event data, and tasks such as fault localization and problem determination become more difficult. As a result, tools are needed that can assist in performing these management tasks by responding quickly and accurately to the large number of events and alarms that are usually generated by even a single fault. Currently this task is usually done using event correlation techniques that utilize network dependency models to integrate the information provided by multiple alarms in order to determine the most likely cause of the problem. [3,4,5,6]
Probing technology is widely used to measure the quality of network performance, often motivated by the requirements of service-level-agreements. A probe is a program that executes on a particular machine (called a probing station) by sending a command or transaction to a server or network element and measuring the response (See FIG. 1). Examples of probing technology include the T.J. Watson EPP technology [1] and the Keynote product [2]. Probing offers the opportunity to develop an approach to problem determination that is more active than traditional event correlation and other methods.
Several decisions are needed to use probes in practice. First, probing stations must be selected at one or more locations in the network. Second, the probes must be configured—it must be decided which network elements to target and which station each probe should originate from. Configuring a probe set in order to perform fault localization requires certain trade offs; the objective is to obtain a probe set which is both small, thereby minimizing network load and the costs of storing the probe results, yet also provides wide coverage, in order to locate problems anywhere in the network.